2022-07-09, in which it quickly becomes clear that I need to figure out how to manage state

What am I going to make?

Immediately a digression on computers — “what are they good at” vs “what are they useful for”

A short list (not comprehensive):

Good at:

Useful for:

Where's the overlap on the Venn diagram of “Good at” and “Useful for?”

Modes of representation that rely on data abstraction, storage, and management — statefulness.

…so, games!

Alright, I admit that this is a weak sauce argument — I've offered no definition of “games,” “representation” is a wishy washy word in this context, and there are well and away other things that fall within this bananas broad category I've conjured…thankfully this isn't a thesis or a treatise or screed or even a rant so I'll allow myself a dab of the weak sauce.

If not a rant, what is this?

Planning, by ways of digital scrying.

What am I going to make?

I'm leaning towards making a game, or a tool to make games with.

I've made games, or tried to make games, in the past. I usually get caught up worrying about portability and struggling with base-level implementation stuff. This results in my never actually making it to what I care about which is state management, rules, and story.

So I figure I might as well start with an experiment: what if I start from state management, rules and story and layer on the stuff that has historically tripped me up later on?

I can theorize and speculate forever. My instinct now is to reach for a book, but let's get messy!

Pseudo code time!

First, define the boundaries of the 2d world,


      0   constant WORLD-MIN-X
      0   constant WORLD-MIN-Y
      100 constant WORLD-MAX-X
      100 constant WORLD-MAX-Y

Next a word that exposes elements of the world at a given location, x:y

: world:x:y ( nn -- s ) ;

My stack comment makes it look like world:x:y returns a string, but I think ideally it would probably invoke either another word or access some sort of data structure that contained the world's data.

Working in forth this is where I tend to get tripped up. Using scheme or lisp I'd define the world as a list of rooms/areas. Then I'd maintain another list of the player's state, including the player's location in the world.

In JavaScript or Lua I'd do something similar, but probably rely on objects (I know, I know, everything is a table in Lua).

…while this is possible in forth, it doesn't feel very forth-y…and isn't something “baked in” to most forth systems.

Another digression; why the heck am I using forth!?

Well, to be totally frank, I'm not sure I'll actually use forth. But I like using it as a design tool. I find that forth invites decomposing problems to component parts, and I find that helpful in reasoning through a system.

Doesn't scheme do the same thing, you may be asking?

…well, yes…and maybe my pretending to speak as 2 people here indicates I should consider using scheme?

Back to code!

Let's say that world:x:y returns something like an object, including info about that position in the world, as well as any interactions that are possible. It would be called through a player:move word,

: player:move ;

This word would take player input and update the player state construct to reflect player's location. It would also return what is up in the world:x:y.

The big missing pieces here are how the world is encoded, how the player's state is encoded, and anything have to do with handling the player input…and everything else.

Player input is something that I'm not heaps concerned about right now. The problem for me to solve is how to handle encoding both player state and info about the world.

…but maybe I wanna make a card game? Still gotta deal with statefulness.

It seems like the first thing for me to tackle, especially if I wanna try to keep moving forward in forth, is to sort out how best to manage state. Anyone have recommendations?